fix(astro): defer to @sentry/cloudflare/vite on Cloudflare Workers - #25347

On Cloudflare Workers, an Astro app needed a hand-written
`sentry.server.config.*` that wraps the adapter's handler, set as the
wrangler `main`. The integration's own Cloudflare plugin wraps
`astrojs-ssr-virtual-entry`, which `@astrojs/cloudflare` v13 and later
no longer emit, so on those versions it wraps nothing.

`@sentry/cloudflare/vite` can now wrap a package `main`, such as
`@astrojs/cloudflare/entrypoints/server`. When the user adds
`sentryCloudflareVitePlugin()` to the Vite plugins in `astro.config`,
the integration now leaves the Worker to it:

- It does not add its own Cloudflare wrap plugin.
- It does not add its orchestrion plugin, because the Cloudflare plugin
  adds one with the workerd-safe `diagnostics_channel` module.
- It does not inject the default server init. That init reads
  `PUBLIC_SENTRY_DSN`, which is not set on Workers, so it disabled the
  transport. The Cloudflare plugin inits the SDK from
  `instrument.server.*` beside the wrangler config, or from `env`.

The integration detects the plugin by name. Importing it would load
`@sentry/cloudflare` and `wrangler` for every Astro app.

Apps without the plugin keep the integration's own wrap plugin. It now
also matches `virtual:cloudflare/worker-entry`, the entry module of
`@cloudflare/vite-plugin`, which v13 and later build through. That
entry ends in `export default mod.default ?? {};`, so the plugin now
wraps any default export expression, not only a dotted name. When the
user's `main` already wraps the handler, the second `withSentry` call
does nothing new, because each handler method is patched only once.

The `astro-6-cf-workers` e2e app now uses the new setup: `main` is the
adapter's entry, and the options live in `instrument.server.js`.

Fixes JS-3934
Fixes JS-2893

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>